Variable length coding (VLC) is a fundamental technology used in encoding source data, and compresses the data by allocating code words of different lengths according to the likelihood of a particular data source symbol. Using coding rules such as shown in FIG. 24, for example, values (codeNum) greater than 0 are converted to variable length code words of 1, 3, 5, . . . bits. Note that the bit string part denoted xn, xn-1, . . . x0 is the part of the bit string that varies according to the data value (codeNum). For example, a value (codeNum) of 1 or 2 is encoded to a 3 bit code word, and values from 7 to 14 are converted to a 7 bit code word. The length of the code words after encoding thus varies according to the data value (codeNum) being encoded by VLC.
VLC is used in encoding standards for motion picture represented by MPEG. More particularly, Target to which VLC is applied is classified into syntax of video encoded data such as the DCT coefficient and motion vectors of image pixel blocks, and syntax for the header. As the coding tools used in image compression technology have become more versatile and complex, the syntax types used in the header have also increased, and VLC is increasingly used in the header syntax in order to reduce the code size.
The H.264/AVC standard (ISO/IEC 14496-10) (see ISO/IEC 14496-10, Advanced video coding for generic audio/visual services) also uses VLC for various syntax included in the sequence parameter set (SPS), the picture parameter set (PPS) and the Slice header.
FIG. 21 to FIG. 23 outline the syntax of the SPS, PPS, and slice header. “Descriptor” of ue(v) or se(v) in these figures denotes a VLC syntax, where ue(v) indicates coding values (codeNum) greater than 0 to VLC words of 1, 3, 5, . . . bits as shown in FIG. 24, and se(v) indicates coding in VLC as shown in FIG. 24 after first converting signed values to a codeNum as shown in FIG. 25.
Configuration of the H.264 byte stream is described next with reference to FIG. 26 to FIG. 29. The image coding data is stored in the slice data (slice_data) shown in FIG. 28. A slice is one division of the picture divided into n parts (n≧1), and is a set of macroblocks. The slice data is coded with the slice header in a slice layer (slice_layer_without_partitioning_rbsp) shown in FIG. 27. The SPS, PPS, and slice layer are packetized as a NAL unit (nal_unit) shown in FIG. 26. When NAL units containing the SPS, PPS, and slice layer are multiplexed into a single stream, the NAL units are packetized into byte stream NAL units (byte_stream_nal_unit, “BNU” below) connected in a single byte stream.
The process to connect plural H.264 byte streams by the video editing device is described next with reference to FIG. 30. More specifically, FIG. 30 shows the process of connecting substream a (153) in stream A (150) and substream b (163) in stream B (160) to generate byte stream C (170).
Stream A (150) includes the byte stream NAL unit (SPS-BNU) 151 of the SPS 110, the byte stream NAL unit (PPS-BNU) 152 of the PPS 111, and the substream a (153) of the scene to be connected to substream b (163). Likewise, stream B (160) includes the SPS-BNU 161, the PPS-BNU 162, and the substream b (163) of the scene to be connected to substream a (153). Each substream a (153) and substream b (163) contains one or more sets including a byte/NAL header (for example, 101), slice header (for example, 120), and slice data (for example, 121).
In this example it is assumed that stream A (150) and stream B (160) contain IDR (Instantaneous Decoding Refresh) pictures, and the code size of all IDR pictures is the same in stream A (150) and stream B (160). The SPS and PPS are also assumed to be at the beginning of the byte stream.
The H.264 standard uses the idr_pic_id as the IDR picture identifier (ID). As shown in FIG. 23, the idr_pic_id is found in the slice header and contains a VLC value. To assure stream compatibility, the H.264 standard requires that the idr_pic_id of adjacent IDR pictures are set to different values.
The process of connecting substream a (153) and substream b (163) based on the foregoing assumptions generates a new byte stream C (170) by connecting substream a (153) and substream b (163) while rewriting the idr_pic_id contained in all of the slice headers in the pictures where the streams are connected to different values in adjacent pictures in order to assure readability and compatibility. More specifically, each of the adjacent pictures in stream A (150) and stream B (160) before the streams are connected is assigned a different idr_pic_id, and it is also necessary to ensure that the pictures that are adjacent where the streams are connected are also assigned a different idr_pic_id after the streams are connected.